Method and semiconductor circuit for protecting an operating system of a security system of a vehicle

ABSTRACT

The disclosure relates to a method for protecting an operating system of a security system, which is stored in a working memory of a control device of a vehicle, against irregular modification.

TECHNICAL FIELD

The disclosure relates to a method for protecting an operating system ofa security system, which is stored in a working memory of a controldevice of a vehicle, against irregular modification.

BACKGROUND

Typically, a vehicle comprises a plurality of different functionalsystems that increase the safety of the vehicle in road traffic or thecomfort of occupants of the vehicle. The security systems (safety) ofthe vehicle include, for example, a braking system and an enginecontrol, while an infotainment system and an air conditioning system areconsidered to be part of the comfort systems of the vehicle.

Each functional system usually comprises at least one device arranged inthe vehicle and an operating system (OS) corresponding to the device,which has a control logic for the device and is stored and executed in acontrol device of the vehicle. The operating system of this disclosurecomprises an operating system in the narrower sense (for example, aLinux kernel) and/or at least one specific application program relatedto the respective device.

The at least one corresponding device, which is naturally arranged inthe vehicle at a distance from the control device, is connectedbidirectionally to the control device, usually via a specific bussystem. Control data or status data are exchanged via the bus systembetween the operating system stored in the control device and the atleast one corresponding device.

The control device and the at least one device are each connected to thebus system by means of a suitable interface. Particularly in the case ofa security system of the vehicle, the bus system and the interfaces mustat any time ensure a real-time communication between the operatingsystem and the at least one corresponding device.

For example, DE 10 2005 048 595 A1 discloses a so-called FlexRayinterface, by means of which a FlexRay participant, i.e., a controldevice or a device of the vehicle, can be connected to a FlexRay bus. Onthe side of the participant, the FlexRay interface comprises an inputbuffer memory and an output buffer memory, each having a partial buffermemory and a shadow memory corresponding to the partial buffer memory.By an alternating read or write access of the FlexRay participant to thepartial buffer memory and the shadow memory of the input buffer memoryor the output buffer memory of the FlexRay interface, the datatransmission between the FlexRay participant and the FlexRay bus can beaccelerated.

In addition to a fast data exchange via the bus system, especially anintegrity of its operating system in the control device must always beensured for a correct functioning of a functional system. The integrityis a necessary requirement for an error-free execution of the operatingsystem stored in the working memory of the control device. It can beachieved by a corresponding protection system (security) for theoperating system.

For example, if an operating system is updated online during a drive ofthe vehicle, undefined intermediate states of the operating system canoccur in the working memory of the control device, which can impair itsproper functioning, particularly in the case of extensive operatingsystems and a correspondingly long update duration.

For protection against such malfunctions during an update, U.S. patentapplication 2009/0119657 discloses a method for updating applicationprograms in a working memory of a control device of a vehicle. In themethod, an updated version of an application program can first be storedin a buffer memory, called “shadow memory,” of the control device topreclude a malfunction of the vehicle due to an undefined intermediatestate of the corresponding application program in case of an extensiveupdate during a drive of the vehicle. The updated version of theoperating system stored in the “shadow memory” is then mirrored into theworking memory upon the next start of the vehicle, i.e., before thestart of the drive, in order to take effect.

In modern vehicles, a plurality of control devices is increasinglycombined in a central control device (electronic control unit, ECU). Thecentral control device has a working memory, in which a plurality ofoperating systems is stored simultaneously and executed in parallel.This configuration is usually termed virtualization. Accordingly, anoperating system with this configuration is called “virtualized.”

In this case, the integrity of an operating system in the working memoryof the control device can be affected by other operating systems storedin the working memory of the control device. For example, byoverwriting, an operating system can modify memory areas of a furtheroperating system either intentionally, i.e., in the course of a targetedattack, or unintentionally, i.e., as a result of a programming error.

This risk is further increased by the fact that different functionalsystems of a vehicle are usually supplied by different manufacturers,and operating systems of different manufacturers are thus simultaneouslystored and executed in the working memory of the control device. Inaddition, operating systems provided independently of each functionalsystem of the vehicle and provided by previously unknown manufacturers,for example, for free surfing of the Internet, can be stored andexecuted in the working memory of the control device. Protection againsta mutual modification of a plurality of operating systems stored andexecuted in the working memory, even from different manufacturers, canbe effected in different ways.

DE 10 2006 054 705 A1, for example, discloses a method for operating anapplication program stored in a working memory of a control device of avehicle, the application program comprising a plurality of programportions of different origin. Each program portion is stored in aseparate working memory area. In order to prevent an irregularmodification of a program portion stored in a first working memory areaby a program portion stored in a second working memory area and thus amalfunction of the application program, the method defines access rightsfor each program portion of the application program in relation to theworking memory areas. If a program portion has to be modified as part ofa regular update, the corresponding memory area can also be mirroredinto a shadow memory for protection purposes.

A modern central control device can also comprise a highly integratedsemiconductor circuit (system on chip, SoC) which combines all thefunctions required for parallel execution of multiple virtualizedoperating systems in one component, particularly a working memory andone or more processors operating in the working memory. If operatingsystems of security systems and operating systems of comfort systems aresimultaneously stored and executed in parallel on the highly integratedsemiconductor circuit, it must be ensured that the operating systems ofthe security systems are protected against irregular modification, whileconventional functionalities of the comfort systems must not berestricted or excluded by a protection system.

A common measure in highly integrated semiconductor circuits is the useof a so-called hypervisor (virtual machine monitor, VMM) as a protectionsystem for the working memory. A hypervisor is configured to monitorand, if necessary, prevent access to the working memory. It is thereforeparticularly well-suited for virtualized systems in order to separateseveral operating systems simultaneously stored and executed in parallelin a working memory. However, the working memory can be affected by theaccesses of the hypervisor which are continuously required in the courseof the monitoring and can lead to errors when executing a hypervisedoperating system.

However, this is unacceptable in the case of an operating system of asecurity system. Furthermore, a hypervisor itself can also be the targetof an irregular modification or irregularly modify the monitored memoryarea as a result of a programming error. Therefore, a hypervisor mustcomply with the international standard ISO 26262, which must beconfirmed for the first time by an ASIL certification prior toactivation and subsequently regularly for each update. However,especially with regard to a usually high update frequency of thehypervisor, the ASIL certification represents a practicallyinsurmountable hurdle, which is why a hypervisor is unsuitable formonitoring a security-critical operating system on a highly integratedsemiconductor circuit.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a schematic block diagram of a non-practical semiconductorcircuit.

FIG. 2 shows a schematic block diagram of a semiconductor circuit,according to some embodiments of the disclosure.

FIG. 3 shows a schematic block diagram of a semiconductor circuit withassociated processors, according to some embodiments of the disclosure.

FIG. 4 shows a schematic detailed depiction of a mode of operation of afirst configuration list, according to some embodiments of thedisclosure.

FIG. 5 shows a schematic detailed depiction of a mode of operation of asecond configuration list, according to some embodiments of thedisclosure.

DETAILED DESCRIPTION

The present disclosure addresses the problem of proposing an improvedmethod for protecting a security system against irregular modifications,which avoids the disadvantages described. The disclosure furtheraddresses the problem of creating a highly integrated semiconductorcircuit which is suitable for executing such a method.

A subject matter of the present disclosure is a method for protecting anoperating system of a security system, which is stored in a workingmemory of a control device of a vehicle, against irregular modification.

In the method according to the disclosure, at least one working memoryarea, which stores at least a portion of the operating system of thesecurity system, is mirrored by a shadow memory manager from the workingmemory into a shadow memory. The shadow memory manager constitutes afunctional module that is designed to establish identity between a firstspecific memory area and a second specific memory area, i.e., to mirrorthe first specific memory area into the second specific memory area. Asa result of the mirroring, a shadow memory area exists in the shadowmemory which constitutes an identical image of the mirrored workingmemory area. As such, the shadow memory area also stores the at leastone mirrored portion of the security system. For example, the portioncan be a single application program of the security-critical operatingsystem.

Furthermore, according to the disclosure, a shadow memory areacorresponding to the at least one mirrored working memory area ismonitored. When the working memory area shows an irregular modification,the shadow memory area shows the same irregular modification due to thecontent identity of the working memory area and the shadow memory area.However, access by a protection system to the shadow memory area formonitoring cannot affect the mirrored working memory area. For example,a protection system could irregularly modify the monitored memory areadue to a programming error. Therefore, if a portion of an operatingsystem of a security system is stored in the mirrored working memoryarea, both a correct execution of the security system and a monitoringof the mirrored portion of the security-critical operating system arepossible. As a result, the execution and the protection of the mirroredportion of the security-critical operating system take place in separatememories and are thus separated from each other.

In a preferred embodiment, the at least one working memory area ismirrored automatically and in parallel into the shadow memory by theshadow memory manager. In this way, it can be ensured that there is nodifference between the at least one working memory area and thecorresponding shadow memory area, whereby monitoring the shadow memoryarea is equivalent to monitoring the working memory area.

In a further embodiment, at least one working memory area, which storesat least a portion of a comfort system, is mirrored from the workingmemory into the shadow memory by the shadow memory manager. Of course,the method can be executed for any working memory areas of the workingmemory, i.e., even those in which portions of a comfort program orportions of a hypervisor are stored.

In some embodiments, the shadow memory manager is configured with aconfiguration list that defines at least one working memory area to bemirrored into the shadow memory. The configuration list is a suitablemeans for determining the effect of the shadow memory manager. Theconfiguration list can comprise one or more working memory areas thatare mirrored by the shadow memory manager into the shadow memory.

In some embodiments, the shadow memory manager is configured, and so asummed memory capacity of the working memory areas to be mirrored issmaller than a total memory capacity of the working memory. In thisconfiguration, not all working memory areas are thus mirrored. Forexample, it is possible to forego a mirroring of those working memoryareas which do not store any portions of a security-critical operatingsystem.

In some embodiments, the shadow memory manager is configured during astart-up of the control device or protected during the operation of thecontrol device. In this way, an attack on the configuration list can beprevented during the configuration.

In some embodiments, an accessing of a working memory area storing atleast a portion of a comfort system is monitored by a hypervisor and/oran accessing of a shadow memory area, which corresponds to a workingmemory area storing at least a portion of the at least one securitysystem, is monitored by a security inspector. The hypervisor constitutesa suitable protection system for portions of non-security-criticaloperating systems which are stored in working memory areas, where theycan be monitored directly. However, for portions of security-criticaloperating systems, a dedicated protection inspector, which is differentfrom the hypervisor, is advantageous as a specific protection system.The protection inspector monitors only the shadow memory. Unlike thehypervisor, it can thus not be irregularly modified by a portion of anoperating system stored in a working memory area.

In some embodiments, at least one operating system of a security systemor comfort system stored in the working memory is executed by at leastone dedicated processor which is exclusively assigned to the operatingsystem. In this way, an isolation of an operating system of a securitysystem from operating systems of comfort systems is also achieved on theprocessor side, which is accompanied by a further improvement of theprotection of the security-critical operating system.

A subject matter of the disclosure is also an integrated semiconductorcircuit for protecting a security system from an irregular modification,comprising, in an integrated topology, a working memory for storing atleast one operating system of a security system and at least oneoperating system of a comfort system, at least one processor forexecuting the at least one operating system of the security system andthe at least one operating system of the comfort system, and a shadowmemory manager which is configured to mirror at least one working memoryarea, which stores a portion of the operating system of the securitysystem, from the working memory into a shadow memory, according to someembodiment of the present disclosure. With a highly integratedsemiconductor circuit which, by means of a shadow memory manager, allowsfor an indirect monitoring of a working memory area which stores aportion of a security-critical operating system, portions of asecurity-critical operating system can be monitored separately fromportions of an operating system of a comfort system. Advantageously, theshadow memory manager is realized as a part of the semiconductor circuitin a hardware. This achieves the highest possible speed when mirroringworking memory areas.

In some embodiments, the semiconductor circuit comprises a configurationlist of the shadow memory manager. A configuration list realized in ahardware cannot be modified by an operating system. As a result, theconfiguration list is effectively protected against modification,particularly an attack.

In some embodiments, the semiconductor circuit comprises the shadowmemory, and particularly a memory capacity of the shadow memory issmaller than a memory capacity of the working memory, or the shadowmemory manager is configured to mirror the at least one working memoryarea into an external shadow memory, particularly a double data rate(DDR) memory module, which is controllable by the semiconductor circuitor externally, and has particularly a storage capacity which is smallerthan a storage capacity of the working memory. Accordingly, severaldifferent forms of realization come into consideration for the shadowmemory. One option is that of providing the shadow memory in the courseof the SoC design as part of the highly integrated semiconductorcircuit. Alternatively, it can also be realized by an external memorymodule. For economic and functional reasons, the shadow memory shouldnot be oversized. It only has to be sufficiently dimensioned toaccommodate specific portions of security-critical operating systems.

In the drawings, the disclosure is depicted schematically by means ofembodiments and shall be further described with reference to thedrawings.

FIG. 1 shows a schematic block diagram of a nonpractical semiconductorcircuit 10 for a control device of a vehicle. The highly integrated SoCsemiconductor circuit 10 comprises a physical functional hardware 11which stores and executes a hypervisor 80, an operating system 50 of asecurity system of the vehicle, and an operating system 60 of a comfortsystem of the vehicle. During operation of the semiconductor circuit 10,the hypervisor 80 monitors memory accesses of the security-criticaloperating system 50 as well as memory accesses of the comfort-relatedoperating system 60. However, the hypervisor 80 can be modified andcorrupted by the operating systems 50 or 60. In addition, the monitoringof the security-critical operating system 50 by the hypervisor 80 canprevent a correct execution of the security-critical operating system50. In this embodiment, the hypervisor 80 would additionally need to beASIL certified prior to the initial start-up and for each update inorder to confirm compliance of the hypervisor 80 with the internationalstandard ISO 26262 with respect to the security-critical operatingsystem.

FIG. 2 shows a schematic block diagram of a semiconductor circuit 100according to some embodiments of the disclosure. Analogously to thesemiconductor circuit 10 shown in FIG. 1, the highly integrated SoCsemiconductor circuit 100 comprises a physical functional hardware 11which simultaneously stores and executes in parallel a hypervisor 80, anoperating system 50 of a security system of the vehicle, and threeoperating systems 60 of comfort systems of the vehicle. In contrast tothe semiconductor circuit shown in FIG. 1, the semiconductor circuit 100additionally comprises a separate shadow memory 70 and a shadow memorymanager 40 which is configured to mirror the security-critical operatingsystem 50 into the shadow memory 70. The semiconductor circuit 100further comprises a security inspector 90 which is a protection systemfor the shadow memory 70 and designed separately from the hypervisor 80.

During operation of the semiconductor circuit 100, the shadow memorymanager 40 mirrors the security-critical operating system 50 into theshadow memory 70 which is monitored by the security inspector 90. Asshown in FIG. 1, the three comfort-related operating systems 60 aremonitored by the hypervisor 80.

FIG. 3 shows a schematic block diagram of the semiconductor circuit 100shown in FIG. 2 with associated processors. In this embodiment, eachprocessor 30 is associated with the security-critical operating system50, the security inspector 90, a comfort-related operating system 60,and two comfort-related operating systems 60.

FIG. 4 shows a schematic detailed depiction of a mode of operation of afirst configuration list 41 according to some embodiments of thedisclosure. A security-critical operating system 50 and twocomfort-related operating systems 60 are stored in a working memory 20.The security-critical operating system 50 is separated from each of thetwo comfort-related operating systems 60 by a separation area 21. Thesecurity-critical operating system 50 includes several portions App 1,App 2, App 3, . . . , App N, App N+1, which constitute individualapplication programs and are stored in a working memory area 51. Ashadow memory manager 40 has a configuration list 41 which comprisesthree working memory areas 51 in which the portions App 1, App 3, . . ., and App N of the security-critical operating system 50 are stored.

During operation, the shadow memory manager 40 mirrors the workingmemory areas 51 defined in the configuration list 41 into a shadowmemory 70, in which copies of the mirrored working memory areas 51 arestored in corresponding shadow memory areas 71.

FIG. 5 shows a detailed schematic depiction of a mode of operation of asecond configuration list 41 according to some embodiments of thedisclosure. In contrast to FIG. 4, a first security-critical operatingsystem 50, a second security-critical operating system 50, and acomfort-related operating system 60 are stored in the working memory 20.The second security-critical operating system 50 comprises a portion AppM, which is stored in a working memory area 51, and the comfort-relatedoperating system 60 comprises a portion App X, which is stored in aworking memory area 61.

The configuration list 41 comprises five working memory areas 51, 61, inwhich the portions App 1, App2, App 3, . . . , and App N of the firstsecurity-critical operating system 50, a portion App M of the secondsecurity-critical operating system 50, and a portion App X of thecomfort-related operating system 60 are stored.

During operation, the shadow memory manager 40 mirrors the workingmemory areas 51, 61 defined in the configuration list 41 into the shadowmemory 70, in which copies of the mirrored working memory areas 51, 61are stored in corresponding shadow memory areas 71, 72.

A significant advantage of the method according to the disclosure isthat portions of a security-critical operating system 50 are notmonitored directly in the working memory 20 but in a mirrored manner inthe shadow memory 70. It is further advantageous because a separatesecurity inspector 90 is used for protecting the shadow memory 70, theseparate security inspector 90 being different from the hypervisor 80provided for protecting comfort-related operating systems. In thismanner, a clean separation between the protection of security-criticaloperating systems and comfort-related operating systems is achieved.

LIST OF REFERENCE SIGNS

10 Semiconductor circuit (prior art)

100 Semiconductor circuit

11 Physical functional hardware

20 Working memory

21 Separation area

30 Processor

40 Shadow memory manager

41 Configuration list

50 Operating system of a security system

51 Working memory area with a portion of the security-critical operatingsystem stored therein

60 Operating system of a comfort system

61 Working memory area with a portion of the comfort-related operatingsystem stored therein

70 Shadow memory

71 Shadow memory area with a portion of the security-critical operatingsystem mirrored therein

72 Shadow memory area with a portion of the comfort-related operatingsystem mirrored therein

80 Hypervisor

90 Security inspector

1.-10. (canceled)
 11. A method for protecting an operating system of asecurity system in a vehicle against irregular modification, comprising:storing the operating system of the security system in a working memoryof a control device of the vehicle; storing, in a first working memoryarea of the working memory, at least a portion of the operating systemof the security system; mirroring, by a shadow memory manager, the firstworking memory area from the working memory into a shadow memory; andmonitoring a shadow memory area within the shadow memory, the shadowmemory area corresponding to the mirrored first working memory area. 12.The method according to claim 11, wherein the mirroring includes:mirroring, automatically and in parallel, the first working memory areafrom the working memory into the shadow memory by the shadow memorymanager.
 13. The method according to claim 11, further comprising:storing, in a second working memory area of the working memory, at leasta portion of an operating system of a comfort system; and mirroring, bythe shadow memory manager, the second working memory area from theworking memory into the shadow memory.
 14. The method according to claim13, further comprising: configuring the shadow memory manager with aconfiguration list; and defining, by the shadow memory manager, thefirst and second working memory areas to be mirrored into the shadowmemory.
 15. The method according to claim 13, further comprising:configuring the shadow memory manager such that a summed memory capacityof the first and second working memory areas to be mirrored is smallerthan a total memory capacity of the working memory.
 16. The methodaccording to claim 13, further comprising: monitoring, by a hypervisor,an accessing of the second working memory area.
 17. The method accordingto claim 11, further comprising: monitoring, by a security inspector, anaccessing of the shadow memory area, wherein the shadow memory areacorresponds to the mirrored first working memory area that stores the atleast a portion of the operating system of the security system.
 18. Themethod according to claim 11, further comprising: configuring the shadowmemory manager during a start-up of the control device.
 19. The methodaccording to claim 11, further comprising: protecting the shadow memorymanager during an operation of the control device.
 20. The methodaccording to claim 11, further comprising: assigning, exclusively, adedicated processor to the operating system of the security systemstored in the working memory; and executing, by the dedicated processor,the operating system of the security system.
 21. A semiconductor circuitfor protecting a security system from an irregular modification,comprising: a working memory configured to store an operating system ofthe security system and an operating system of the comfort system; aprocessor configured to execute the operating system of the securitysystem and the operating system of the comfort system; a shadow memory;and a shadow memory manager configured to mirror a working memory areathat stores at least a portion of the operating system of the securitysystem, from the working memory into the shadow memory, wherein theworking memory, the processor, the shadow memory and the shadow memorymanager are in an integrated topology.
 22. The semiconductor circuitaccording to claim 21, further comprising: a configuration list of theshadow memory manager.
 23. The semiconductor circuit according to claim21, wherein the shadow memory comprises a memory capacity smaller than amemory capacity of the working memory.
 24. The semiconductor circuitaccording to claim 21, wherein the shadow memory is external to thesemiconductor circuit, and is controllable by the semiconductor circuit.25. The semiconductor circuit according to claim 24, wherein the shadowmemory is a double data rate (DDR) memory module.
 26. The semiconductorcircuit according to claim 24, wherein the shadow memory comprises astorage capacity smaller than a storage capacity of the working memory.